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Aunque se suponia que en el numero 9 de 
Rendermama iba a tener lugar la tan 
prometida batalla entre orcos y humanos, al 
final esta quedo reducida a una miserrima 
escaramuza entre zombis y humanos. La 
sustitucion de los orcos por los zombis se 
debio a que por entonces no disponiamos de 
ningun modelo decente de orco, detalle este 
que ya fue subsanado en el numero 11. Mas 
grave fue, sin embargo, el problema del brutal 
consumo de memoria que «POV» parecia 
requerir para representar escenas con cientos 
de modelos (y que redujo la "batalla" a solo 
tres pares de luchadores). Pero, aunque 
parezca increible, este problema se debia tan 
solo a la ignorancia y no a una limitacion de 
«POV». Sabed pues, oh Rendermaniacos y 
Povadictos... ique Mesh nos permitira crear 
primorosas escenas compuestas por cientos 
de modelos complejos! 




ntes de empezar. claro 
esta. debemos pedir 
disculpas a los lectores 
por no haber hablado 
antes de esta importan- 
. ti'sima sentencia del 
lenguaje escenico de «POV». Hace bastan- 
te tiempo, cuando empezamos a leer el 
doctorial de «POV», pasarnos rapidamente 
por Mesh y nos centramos sobre todo en 
las sentencias de programacion, pensando 
eiToneamente que Mesh seria una optimi- 
zation sin importancia. Solamente hace 




batallas virtuales 




unos meses, al preparar el especial so- 
bre «Rhinoceros», comprendimos el 
enorme potencial de esta sentencia 
gracias a que «Rhino» empleaba Mesh 
para exportar sus escenas al formato de 
«POV». Intrigados porello estudiamos 
esta instruccion con algo mas de aten- 
cion y... bueno, ahora vereis. Nuestra 
linica disculpa posible -aunque pobre- 
es que nadie mas parece haber dado a 
Mesh el valor que merece: al menos 
nosotros no hemos encontrado aun una 
sola escena -ni en la red ni en el foro- 



en la que se haya 
empleado a Mesh 
para crear fantas- 
ticas escenas con 
cientos de mode- 
los. ^Por que? En 
fin. puede ser que 
no hayamos bus- 
cado lo suficiente. 
Si este es el caso 
esperamos que al- 
gun amable ren- 
dermanfaco nos 
saque del error. . . 
Tambien quere- 
mos anadir que en 
este artfculo he- 
mos supuesto que 
el lector compren- 
de el funciona- 
miento de #if, 
#while y de otras 
"sentencias de 
programacion" ya 
explicadas hace 
mucho y sobre 

cuya importancia no nos cansaremos 

de insistir. 

Exportation de modelos a 
«P0V» 

Como ya saben los usuarios experi- 
mentados de «POV». nuestro raytracer 
dispone, desde hace mucho, de un par de 
sentencias -triangle y smooth_triangle- 
que le permiten usar objetos construidos 
desde modeladores poligonales como 
«Imagine» o «3D Studio». Para ello ha 
de seguirse el siguiente proceso: 



1) El usuario crea su modelo em- 
pleando su modelador preferido («3D 
Studio», «Imagine», «trueSpace», etc.). 
Con ello obtendra un modelo que no 
sera directamente digerible por «POV» 
(la excepcion esta en el uso de algun 
modelador como «Moray». expresa- 
mente creado para «POV», y de otros 
programas del mismo tipo). En efecto: 
normalmente el modelador guardara la 
malla de triangulos que forma al mode- 
lo como un fichero binario empleando 
un formato propio ininteligible para 
«POV» (3DS en el caso de «3D Stu- 
dio*, obj en el de «Imagine», etc.). 
Aunque tambien es frecuente que estos 
modeladores ofrezcan ademas la op- 
cion de guardar el modelo usando el 
formato DXF o bien un formato ASCII 
sencillo, a fin de facilitar las exporta- 
ciones de objetos a otros programas. 

2) Seguidamente, el usuario debe- 
ra emplear alguna herramienta de con- 
version para "traducir" el archivo ge- 
nerado por el modelador (en numeros 
anteriores ya hemos hablado de algu- 
nas de estas herramientas: 3ds2pov. 
3dto3d. Wcvt2pov, etc.). El resultado 
sera un nuevo fichero en formato AS- 
CII y comprensible para «POV» en el 
que los polfgonos del modelo del ar- 
chivo suministrado como entrada seran 
traducidos a sentencias triangle y smo- 
oth triangle. Estas sentencias fueron 
implementadas en el lenguaje escenico 
de «POV» por el Povteam pensando 
precisamente en el caso de aquellos 
usuarios que deseasen emplear mode- 
los no creados desde el mismo «POV». 
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Teoricamente podn'an ser empleadas 
por el usuario para crear objetos a ma- 
no, empleando un procesador de tex- 
tos, pero esto, a menos que el objeto 
sea algo tan sencillo como un cubo, no 
resulta practice ya que habn'a que cal- 
cular a ojo un monton de coordenadas 
de vertices. 

3) Despues, simplemente, habre- 
mos de incluir el archivo .POV o .INC 
resultante de la "traduction" en nues- 
tro fichero escenico. Para ello escribi- 
remos una o mas ordenes #include en 
el archivo donde se describe nuestra es- 
cena. Esto no siempre sera necesario ya 
que puede ocurrir que todos los ele- 
mentos de la escena ya hayan sido es- 
tablecidos desde el modelador y que no 
deseemos cambiarlos desde «POV». 
En estos casos las utilidades como 
3ds2pov nos vendran de perlas, ya que 
generan archivos .POV en los que se 
"traduce", ademas de a la malla con el 
modelo, a las luces, la colocacion y 
orientation de la camara, los colores de 
los objetos y sus propiedades de super- 
ficie, etc. De esta manera bastara con 
invocar a «POV» y pedirle que renderi- 
ce el archivo .POV generado por la he- 
rramienta de traduction. Asf obtendre- 
mos una imagen muy similar a la que 
podrfamos renderizar desde el modela- 
dor que hayamos usado. 

Para mayor comodidad del usuario, 
las mejores utilidades de conversion 
(como 3ds2pov) generan 2 o mas archi- 
vos para «POV». Suelen crear un fiche- 
ro .POV en el que se incluye la "traduc- 
tion" de la camara y las fuentes de luz, 
y uno o mas archivos .INC donde iran 
las sentencias triangle y smoothjrian- 
gle con la forma del modelo. Para nues- 
tros propositos actuales, o sea para ge- 



nerar escenas complejas con cientos de 
modelos, lo mejor sera colocar cada uno 
de estos modelos en la escena aprove- 
chando las magnfficas capacidades del 
lenguaje escenico de «POV». Por ello 




prescindiremos de los ficheros .POV ge- 
nerados en las conversiones, quedando- 
nos unicamente con los archivos que 
describen la geometrfa de los modelos. 
Sabido esto ya solo nos queda recor- 
dar algunos de los problemas que fasti- 
diaron a nuestra batallita. Uno de ellos 
es que los objetos creados con modela- 
dores poligonales se almacenan como 
mallas de caras compuestas por verti- 
ces, requiriendo cada uno de los cuales 
tres valores en flotante para describir 
su position espacial (y aun puede ser 
necesaria mas memoria para describir 
los vectores de las normales, si estas 
son tambien almacenadas). Esto quiere 
decir que frecuentemente los archivos 
.INC que habremos de manejar seran 
muy grandes, con lo cual «POV» preci- 



sara mucha memoria para incluirlos en 
nuestras escenas. Sin embargo, lo peor 
es que, para cada copia del modelo em- 
pleada en la escena, «POV» requerira 
(usando union) la misma cantidad de 
memoria. Asf, si por ejemplo, un orco 
requiere 6 Megas de RAM, la inclusion 
de 6 monstruos de este tipo en una es- 
cena precisara 36 Megas. Este proble- 
ma fue el mayor obstaculo para la tan 
ansiada batalla orco-humana. 

Mesh: un milagro bien 
sencillo 

Este problema de la excesiva deman- 
da de memoria se debe al empleo de la 
sentencia union. Las utilidades de con- 
version algo antiguas como 3ds2pov y 
3dto3d usan esta sentencia para englo- 
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bar a las sentencias triangle y smoothjrian- 
gle que describen a los modelos importa- 
dos. Como recordareis, union se usa para 
indicar a «POV» que un conjunto de obje- 
tos individuates (en este caso un conjunto 
de triangulos) forman un tinico objeto. An- 
tes de la version 3.0, el uso de union pa- 
ra los objetos importados resultaba im- 
prescindible ya que de esta manera 
bastaba con especificar una unica textu- 
ra que se aplicaba sobre un grupo de 
triangulos (en vez de hacer lo propio pa- 
ra cada triangulo). Ademas, usando esta 
sentencia podfamos colocar sentencias 
de transformation que afectaban a todo 
el grupo de triangulos englobados por la 
union. Sin embargo, union no fue crea- 
da para agrupar triangulos, sino objetos 
creados desde el propio «POV». La 
sentencia mesh, en cambio, si ha sido 
disenada exclusivamente con esta fina- 
lidad y funciona exactamente igual que 
union. La unica diferencia radica en que 
con mesh los grupos de triangulos en- 
globados se almacenan en memoria una 
unica vez. Asi, en la siguiente ocasion 
en que invoquemos al objeto-mesh den- 
tro del fichero de escena, «POV» unica- 
mente precisara una pequena cantidad 
de RAM para generar al objeto, el cual 
sera considerado como una copia del 
primero. Unicamente hay que recordar 
que mesh solo podra ser usada para en- 
globar triangulos (si usamos una senten- 



cia mesh para englobar a varias mesh o 
para englobar a objetos normales, el par- 
ser nos dara el error "No triangles in 
triangle mesh"). 

Dado que las utilidades como 3ds2pov 
o 3dto3d no generan aun ficheros con 
mesh sino con union (al menos en las 
versiones mas modernas que hemos po- 
dido encontrar), deberemos -si usamos 
estas herramientas y queremos aprove- 
char la potencia de mesh- emplear un 
editor de textos para sustituir las senten- 
cias union por mesh. Otros programas 
mas modernos como «3Dwin 3.0» de 
Thomas Baier (que hemos incluido en 
el CD) si generan conversiones mesh. 

Seguidamente comentaremos la for- 
ma mas adecuada de usar mesh y estu- 
diaremos la lista de experimentos que 
llevamos a cabo para usar mesh con 
modelos antropomorficos y que de- 
semboco en las diversas escenas que 
ilustran este numero. 

Creando nuestro primer 
regimiento de orcos 

El modelo de orco empleado para 
crear las escenas basicas de nuestro re- 
gimiento de ejemplo es el que presenta- 
mos en el numero 1 1 de Rendermam'a. 
La cabeza de este orco fue creada con 
«Rhinoceros», el cual si hace exporta- 
ciones con mesh, por lo que no fue de- 
masiado dificil preparer a la menciona- 
da cabeza para usarla en los primeros 
experimentos hechos para comprobar 
el funcionamiento de esta 
sentencia. Lo mismo ca- 
be decir del cuerpo, el 
cual esta basado en una 
malla que hallamos por la 
Red. La cabeza original 
de dicha malla fue elimi- 



nada y las proporciones del cuerpo alte- 
radas desde «Rhino» para adecuarlas a 
las formas exageradas y monstruosas de 
los orcos. En cuanto al faldelh'n y a las 
armas se hicieron tambien en «Rhino» 
o se importaron de «Imagine». Por ulti- 
mo, el modelo completo se exporto a 
«POV» en varios archivos; uno para la 
cabeza, otro para el cuerpo y otro para 
las armas. . . (al menos asf fue en las pri- 
meraspruebas). 

Ahora veamos la forma mas sencilla 
de emplear Mesh. Despues de utilizar 
una herramienta de conversion lo mas 
probable sera que obtengamos uno o mas 
archivos .INC, cada uno de los cuales es- 
tara formado por varias sentencias union 
o mesh (dependiendo de si la herramien- 
ta usada es un poco antigua o no). Lue- 
go, para cada fichero, sustituiremos -si 
las hay- a las sentencias union que en- 
globen a los triangulos por instruccio- 
nes mesh. Tambien deberemos elimi- 
nar, si las hubiera, las definiciones de la 
camara y de las fuentes de luz. (En el 
caso de 3ds2pov, todo esto se pone 
aparte pero no todas las utilidades de 
conversion funcionan igual). Por ulti- 
mo, y en caso de que no la hubiera, de- 
beremos crear una union que englobe a 
todas las mesh del fichero .INC sobre 
el que estemos trabajando. Este ultimo 
paso sera imprescindible para referen- 
ciar luego a las mallas desde el fichero 
de escena con sentencias como las que 
podeis ver en el cuadro 1. 



#declare cuerpol=object(#include "bodyl.inc" 



object{cuerpol} 
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Asi, cuando «POV» este compilando 
la escena, al encontrar el include, el 
programa ira cargando el archivo y pa- 
sando los datos de las mallas a la 
RAM. Mas tarde, el modelo podra ser 
invocado cuantas veces deseemos 
usando sentencias object y «POV» tan 
solo precisara una pequena cantidad de 
memoria para los datos propios de cada 
referenda al objeto inicial. Ni que decir 
tiene que seria una estupidez usar sen- 
tencias como... 

object{#include "bodyl.inc"} 
...cada vez que deseasemos crear un nue- 
vo modelo en la escena, ya que entonces 
«POV» cargaria nuevamente el archivo 
cada vez que hallara una de estas senten- 
cias en el fichero de escena. Examinad 
el listado de la siguiente figura. 

"Ejemplo de creacion de un cuadro de 
guerreros orcos" 

#declare orcol=object{#include "orco.inc"} 

#declare nfilas=8 

#declare xpos=0 

#declare zpos=0 

#wnile(colum!=0) 

#declare xpos=0 

#declare fila=8 

#while(fila!=0) 

objectforcol translate <xpos,0,zpos> } 
#declare xpos=xpos+120 
#declare fila=fila-l 

#end 

#declare zpos=zpos+120 

#declare nfilas=nfilas-l 
#end 



Este ejemplo corresponde a una de 
las primeras pruebas con mesh (cuando 
el orco aiin no habia sido dividido en 
piezas) y en el se crea a un cuadro de 
8x8 guerreros orcos. En esta y en las si- 
guientes pruebas las "sentencias de 
programacion" fueron imprescindibles 
para crear grandes grupos de guerreros. 



Estadisticas 

Para hacemos una idea 
cabal de lo conveniente 
que es el uso de mesh vale 
la pena citar algunas esta- 
disticas recogidas tras las 
primeras pruebas con esta 
sentencia. Las mallas del 
orco completo tienen mu- 
chos triangulos y por ello. 
tras realizar el primer ren- 
der para una sola de estas 
criaturillas. pudimos ver 
en la pantalla de estadisti- 
cas la nada desdenable ci- 
fra de 14.612.203 bytes. 
;Casi 14 Megas de RAM 
para un solo orco! Sin em- 
bargo, al anadir 63 orcos 
mas a la escena, el gasto 
de memoria tan solo as- 
cendio a unos 2 Megas 
mas. Por otro lado, para 
otros modelos menos 
complejos como el del 
lancero, el gasto de me- 
moria fue aiin menor. A 
priori resulta imposible 
predecir la cantidad total 
de memoria que precisare- 
mos para crear un grupo 
de objetos-copia (asi los 
llamaremos desde ahora). 
Solo podemos estar segu- 
ros de una cosa, el ahorro 
de memoria sera impresionante y ademas 
podremos manipular a los objetos-copia 
de maneras sumamente interesantes. 

Perfeccionando el regimiento 
de orcos 

En la primera prueba se creo una 
formation cuadrada de 8x8 orcos. Este 
cuadro de guerreros no resultaba de- 







masiado atractivo y el mayor problema 
fue, por supuesto, que todos los orcos 
eran iguales. Este problema solo tenia 
una solution posible: crear mas orcos. 
Pero claro, cada nuevo monstruo hu- 
biera requerido (de emplear la misma 
densidad poligonal y detalle que en el 
primero) otros 12 6 13 Megas de me- 
moria. Ademas, esto solo nos hubiera 
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dado una va- 
riation de 2 
tipos de per- 
sonajes dife- 
rentes dentro 
del cuadro de 
64 orcos, con 
lo cual no hu- 
bieramos 
conseguido 
gran cosa. Fi- 
nalmente, se 

tomaron las siguientes medidas para me- 
jorar el resultado inicial: 

1 ) Se desgloso el modelo comple- 
te del orco en varias partes: el cuerpo, 
la cabeza y las armas. Luego se altero 
el codigo del fichero escenico de ma- 
nera que segun un factor aleatorio se 
colocase la cabeza creada en el nume- 
ro 1 1 o las disefiadas en el 13 con 
Spatch. Ademas se hizo lo mismo con 
las armas y el estandarte (como estos 
objetos se empunan de la misma ma- 
nera y estan colocados en la misma po- 
sition espacial son facilmente inter- 
cambiables). 

2) Los objetos componentes del 
orco se englobaron dentro de una 
union, de manera que pudieran variarse 
las proporciones globales de altura y 
anchura de cada personaje. 

3) Como la alineacion del cuadro 
de guerreros resultaba excesivamente 
perfecta, se introdujeron pequenas al- 
teraciones aleatorias de position en ca- 
da orco. 

4) Se introdujo un pequeno factor 
aleatorio de rotation lateral en la cabe- 
za de cada personaje. 

5) Se alteraron los ficheros .INC 
para que el color basico de la piel de 
cada orco sufriese pequenas variacio- 
nes aleatorias. 



El resultado final -visible en la es- 
cena final de la serie de pruebas- aun- 
que aiin dista bastante de la perfection, 
es muy superior al obtenido en la pri- 
mera imagen de la misma. Sin embar- 
go, lo importante es comprender que 
cada uno de los modelos que aparecen 
en la escena final de la serie ha ocupa- 
do -a pesar de sus leves variaciones 
con respecto al modelo original- tan 
solo una pequena cantidad de memo- 
ria. Viendo esto uno no puede por me- 
nos de preguntarse si no sera posible 
conseguir un resultado aiin mejor, y lo 
cierto es que si que es posible. En el si- 
guiente arti'culo explicaremos como es- 
to puede lograrse siguiendo un curioso 
y sencillo metodo. Por ahora echare- 
mos un vistazo en detalle a los trucos 
que se han empleado para la ultima es- 
cena de la serie. 

Trucos de programacion 

Las llatnadas "sentencias de progra- 
macion" del lenguaje escenico de 
«POV» son vitales para crear escenas 
con cientos o miles de modelos. Por 
ejemplo para crear el cuadro de guerre- 
ros se empleo un bucle anidado dentro 
de otro. El bucle mas interno crea los 
guerreros de cada fila y usa para ello el 
contador fila. El bucle mas exterior se 



encarga 
— usando 
el contador 
nfilas — 
de contro- 
ar el nii- 
mero de 
filas que 
tendra la 
forma- 
cion. Asi, 
por ejem- 
plo, unos valores de 4 y 10 para nfila y 
fila respectivamente crearian una for- 
mation de 4 filas de profundidad con 
1 guerreros en cada fila. Pero, por su- 
puesto, podn'amos haber dado valores 
para crear un cuadro de 400 o mas or- 
cos. (,0s imaginais situandolos en la 
escena a mano? (Gracias al povteam 
por #while). 

Pero sigamos: el guerrero "original" 
(el cargado en memoria con #include) 
esta centrado en los ejes X y Z y tiene 
los pies sobre Y=0. Asi que, para des- 
plazar cada objeto-copia a la position 
adecuada dentro de la formation, po- 
demos usar una sentencia parecida a 
esta 

object{orcol translate <xpos,0,zpos> } 

Naturalmente dentro del bucle inter- 
no la variable xpos se ira actualizando 
en cada pasada del mismo con una sen- 
tencia como... 

#declare xpos=xpos+120 

donde el valor sumado a xpos es la 
separation espacial en el eje X que el 
proximo orco tendra con respecto al ul- 
timo creado en la escena (cuanto mas 
pequena sea la suma para xpos y zpos, 
mas apretados estaran los guerreros 
dentro de la formation). 
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Lo malo de esto es que la formation 
resultante es excesivamente perfecta. 
Conseguiremos un resultado mas real 
si los guerreros se salen levemente de 
la position ideal de cada uno. Para con- 
seguir esto lo mejor sera emplear la 
sentencia rand para afiadir una suma 
aleatoria a los valores de xpos e zpos. 
Echad un vistazo al codigo de la si- 
guiente figura. 



"Ejemplo tornado del fichero de generacion de una de las 
escenas de la serie" 

#declare cuerpol=object{#include "bodyl.inc"} 
#declare cabezal=object{#include "headl.inc"} 
#declare cabeza2=object{#include "head2.inc"} 
#declare cabeza3=object{#include "head3.inc"} 
#declare R=seed(8534) 
#declare colum=l 
#declare xpos=0 
#declare zpos=0 
#while(colum!=0) 
#declare xpos=0 
#declare fila=8 
#while(fila!=0) 
union{ 

object{cuerpol) 
#declare a=int(rand(R)*3) 
#switch (a) 
#case (0) 

objectfcabezal rotate <0,-25 +(rand(R)*50),0>} 
#break 
#case (1) 

object{cabeza2 rotate <0,-25 +(rand(R)*50),0>} 
#break 
#oase (2) 

object{cabeza3 rotate <0,-25 +(rand(R)*50),0>} 
#end 

#declare alto=.8 + rand(R)*.15 
#declare ancho=.90 + rand(R)*.2 
scale <l*ancho,l*alto,l*ancho> 
#declare sumx=-15 +(rand(R)*30) 
#declare sumz=-15 +(rand(R)*30) 
translate <xpos+sumx,0,zpos+sumz> 
} 

#declare xpos=xpos+120 
#declare fila=fila-l 
#end 

#declare zpos=zpos+120 
#declare colum=colum-l 
#end 






En este ejemplo puede verse como 
se anaden a xpos y zpos los valores 
sumx y sumz respectivamente. Estos 
valores representan una variation ale- 
atoria de 30 unidades con respecto a 
la position ideal. Para lograrla se res- 
tan 15 unidades a dicha position y se 
suma el valor aleatorio devuelto por 
rand. Como recordareis rand devuelve 
un valor aleatorio entre y 1 por lo 
que multiplicarel 
valor devuelto 
por 30 equivale a 
obtener un valor 
aleatorio entre 
y 30. Como se 
resta 15 al valor 
de estas varia- 
bles, el resultado 
es que cada orco 
puede ser coloca- 
do dentro de un 
rectangulo espa- 
cial de 30x30 
unidades cuyo 
centro es su posi- 
tion ideal. Logi- 
camente, si cam- 
biamos el valor 
de lasemilladado 
a R (en "#declare 
R=seed(8534)"), 
el "desorden" ob- 
tenido en la for- 
mation sera dife- 
rente. 

Otro detalle a te- 
ner en cuenta es 
que podemos va- 
riar la escala de 
un objeto-copia, 
diferenciandolo 
asi un poco del 
modelo original. 



Esta posibilidad ha sido usada para al- 
terar la altura y el grosor de los orcos, 
logrando asi orcos bajos y anchos y 
otros altos y delgados. Esto se ha con- 
seguido ordenando la siguiente trans- 
formation para la union del modelo 
completo: 

#declare alto- 8 + rand(R)*.15 
#declare ancho=.90 + rand(R)*.2 
scale <l*ancho,l*alto,l*ancho> 

Si exageramos los valores dados a 
alto y ancho obtendremos una varie- 
dad de proporciones aun mayor aun- 
que, por supuesto, seguimos sin po- 
der alterar las formas basicas del 
modelo. Por eso, el resultado es un 
cuadro de guerreros orcos que pare- 
cen todos miembros de un clan fuer- 
temente endogamico. 

Y ya solamente nos queda dar cuen- 
ta de dos detalles. Como veis en el 
ejemplo de la figura, se escoge entre 
una y otra cabeza dependiendo (otra 
vez) de un valor aleatorio. En caso de 
que hubieramos podido disponer de 
mas cabezas hubiera sido sencillo am- 
pliar el switch para incluirlas asi como 
variar la sentencia que asigna su valor a 
"a" (notese el uso de int para forzar a 
«POV» a devolver solo valores enteros 
para el switch). 

En cuanto a la pigmentation tam- 
bien se ha usado un valor aleatorio pa- 
ra alterar un poco la intensidad del 
verde con respecto al color ideal de 
cada orco. Lo mismo se ha hecho con 
el color de la faldita y de la cota de 
mallas. Sobre esto ultimo hay que de- 
cir que realmente no hay cota de ma- 
llas, sino tan solo un color distinto al 
verde de la piel, pero desde lejos po- 
demos dar el pego con un simple cam- 
bio de color. 
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Creadon de modelos-copia 
diferentes al modelo original 

En las paginas precedentes hemos visto como puede emplearse la 
sentencia mesh para crear copias de modelos en «POV». Como dichas 
copias requieren tan solo una pequena cantidad de memoria -en contraste 
con la gran cantidad de RAM que puede requerir el modelo original- esto 

quiere decir que 
podremos crear 
escenas con 
cientos o miles de 
formas complejas. 
Sin embargo, esto 
no es todo lo que 
podemos hacer: 
existe una manera 
sencilla de crear 

modelos-copia y darles posturas diferentes a la original. Es decir, si 
tenemos el tiempo suficiente, podemos crear docenas de posturas de un 
modelo para una escena y emplearlas sin que cada nueva postura precise 
mas espacio del que requeriria un objeto-copia identico al modelo original. 
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ntes de empezar 
conviene aclarar 
que nuestro orco no 
es el modelo mas 
adecuado para ilus- 
trar la tecnica que 
vamos a describir en el presente articu- 
lo. Ello se debe a que el cuerpo del mo- 
delo carece de objetos que sirvan como 
ejes de articulation. Por esta razon, en 
muchas de las posturas pueden apre- 
ciarse huecos en las rodillas. los codos 
o los hombros, con lo que queda de 
manifiesto que el cuerpo del orco no es 
un modelo solido sino tan solo un con- 
junto de formas huecas. Este 
problema ha quedado sin so- 
lution por ahora. ya que no 
habia tiempo para construir 
las formas necesarias e incor- 
porarlas al modelo (bueno. lo 
cierto es que hemos anadido 
unas esferas en las rodillas ya 
que los huecos que aparecian 
eran demasiado reveladores, 
pero esto no pasa de ser un 
apafio provisional). 

Sin embargo, lo realmente 
importante para nuestros pro- 
positos era demostrar la vali- 
dez del metodo que vamos a 
presentar a continuation, y 
para esto el orco resultaba 
mucho mas conveniente que, 
por ejemplo, un mech. 



La idea basica 

En el articulo anterior las 
ultimas escenas fueron crea- 
das dividiendo el modelo de 
orco en tres partes: el cuerpo 
complete las cabezas y las 
armas. De esta manera, cada 
una de estas partes era facil- 



mente intercambiable, lo cual daba al- 
go de variedad a las escenas jjlastima 
no haber tenido tiempo suficiente para 
preparar mas cuerpos! ! 

Hecho esto, nos preguntamos si no 
seria aun mejor almacenar cada parte 
del cuerpo separadamente, a fin de po- 
der aplicar cambios individuals en ca- 
da pieza. <^Y que tipo de cambios? Pues 
no, evidentemente, cambios anatomi- 
cos, puesto que entonces las proporcio- 
nes del modelo habn'an quedado estro- 
peadas, pero si cambios de orientacion 
y de colocacion. Asf. como cada parte 
estaria almacenada usando mesh y co- 




Preparando posturas para el orco. 



mo cada objeto-copia podn'a ser trans- 
formado independientemente, el resul- 
tado seria que podrfamos crear orcos- 
copia con posturas diferentes a la del 
conjunto de piezas del orco original. 

El que esto funcione bien o no de- 
pendera, como en el caso del articulo 
anterior, de que estemos empleando 
una herramienta de traduccion que res- 
pete la colocacion que tenfan los obje- 
tos en el espacio virtual del modelador 
donde fueron creados. Decimos esto 
porque hay algunos traductores 3D que 
olvidan dicha colocacion y que ademas 
reescalan los objetos a su capricho al 
hacer la "traduccion", con lo 
cual no nos serviran para na- 
da. En el caso del orco, este 
fue modificado con «Rhino- 
ceros», programa desde el 
cual se exportaron todos los 
objetos al formato de «POV». 
Luego se comprobo, al crear 
una escena de prueba desde 
«POV», que «Rhino» habia 
respetado la escala, coloca- 
cion y orientacion de cada 
pieza al hacer la grabacion, 
por lo cual el resultado fue un 
orco completo. 

Ahora bien; ^,como crear las 
posturas? Como imaginareis, 
crear cada postura desde 
«POV» estableciendo los va- 
lores de rotation de cada ob- 
jeto es algo muy trabajoso (al 
menos al principio. hasta que 
se acaba cogiendo practica. 
Recordad que algunos esfor- 
zados rendermaniacos lo han 
hecho. Este es el caso de 
Oscar Alvarez Diaz, con su 
soldado imperial de asalto, y 
de Carlos Monterde Escude- 
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ro, con su horda orca). Por es- 
ta razon, y despues de expri- 
mirse un rato las neuronas, el 
autor de estas lfneas ideo el 
siguiente metodo para crear 
cada nueva postura: 

1) «Imagine» es el pro- 
grama donde mas facil y ra- 
pidamente podemos crear 
nuevas posturas de un modelo antropo- 
morfico. Para aprovecharnos de esta 
util caracten'stica de «Imagine» carga- 
remos desde este programa el modelo 
cuyas posturas deseemos crear. 

Para ello deberemos grabar el mode- 
lo desde el modeladorque estemos em- 
pleando y traducirlo luego a un forma- 
to que pueda ser leido desde «Imagine» 
(al suyo propio o al DXF). Otra posi- 
bilidad es, simplemente, emplear un 
modelo antropomorfico similar al del 
orco ya que lo que nos interesa es uni- 
camente tomar nota de los angulos de 
rotacion de las distintas partes del cuer- 
po. Esto ultimo fue lo que se hizo (para 
evitarnos el trabajo de la conversion a 
«Imagine») y empleamos para esto al 
modelo del no-muerto que aparecio en 
Rendermam'a numero 9, usando la 
postura basica del mismo que es igual 
a la basica del orco (o sea, de pie y en 
postura de firmes salvo por las manos 
cerradas en punos). Esto solo tiene un 
inconveniente: puede darse el caso que 
tengamos que hacer ajustes desde 
«POV» dadas las posibles diferencias 
entre el modelo antropomorfico em- 
pleado en «Imagine» y el modelo usa- 
do en «POV». 

2) Desde «Rhinoceros» o «Imagi- 
ne», o desde el programa que hayamos 
empleado para crear nuestro modelo, 
tomaremos nota de la posicion de cada 




eje local de giro. Llamaremos eje local 
al punto espacial donde pivota una pie- 
za corporal o un conjunto de piezas. 
Por ejemplo, habra que definir un eje 
local para la mano (situandolo en la 
muneca), otro para el antebrazo (si- 
tuandolo a la altura del centro del codo) 
y otro para el brazo completo (situan- 
dolo en el centro del hombro). Asi pues 
tomaremos nota de los valores <x,y,z> 
de la posicion de cada eje local. Aten- 
cion: si establecemos mal la posicion de 
estos ejes, luego desde «POV» pueden 
sucedernos cosas tales como que un 
brazo o una pierna se salgan del cuer- 
po. al intentar definir su posicion. 

3 ) Hecho esto crearemos las jerar- 
qufas del modelo -si es que no estaban 
ya creadas- y procederemos a crear la 
postura deseada tomando nota del va- 
lor del angulo para cada pieza y del eje 
en que dicha rotacion va a llevarse a 
cabo. Aquf, naturalmente, lo mejor 
sera que nos hayamos molestado en 
disponer previamente al modelo con 
una orientacion tal que los ejes de ro- 
tacion correspondan a la que normal- 
mente tienen nuestros modelos en 
«POV» (recordad que aquf solemos 
exportar los modelos a «POV» de tal 
manera que el personaje quede de pie 
sobre el piano X-Z, con los pies a la al- 
tura de Y=0 y con los ojos mirando en 
la direction -Z. Esta es la orientacion 



de nuestro orco y tambien la del zombi, 
por lo cual no fue preciso reorientar a 
este en «Imagine»). Hecho esto iremos 
rotando las distintas partes del modelo 
para crear la postura deseada y, al mis- 
mo tiempo, tomaremos nota de los gra- 
dos (visibles en la esquina superior de- 
recha de la pantalla de «Imagine») de 
cada rotacion. Tambien hay que recor- 
dar estipular en nuestras notas donde se 
efectua la rotacion ya que si esta se lle- 
va a cabo en el hombro, por ejemplo, 
habra de afectar al brazo completo. 

4) El ultimo paso sera crear uno o 
mas ficheros plantilla usando el len- 
guaje escenico de «POV» (luego vere- 
mos como). En nuestro caso, un pro- 
yecto que describa una escena en la que 
participen regimientos de orcos se 
compone al menos de 3 tipos de fiche- 
ros: uno con la extension .«POV» que 
describe la escena e invoca a los demas 
archivos, otros que incluyen los valo- 
res de rotacion de cada estructura jerar- 
quica del modelo y otro donde se crea 
una jerarqufa de uniones que imita a las 
jerarqufas del modelo en «Imagine» (o 
a las del modelo usado en su lugar des- 
de este programa). Aunque, por su- 
puesto, esto podn'a hacerse siguiendo 
otro sistema. 

Otro detalle importante que convie- 
ne no olvidar es que muchas utilidades 
de traduction incluyen en las mallas 
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traducidas una textura similar a la que 
tenia el modelo en el programa donde 
fue creado. Pues bien, si queremos re- 
alizar ciertos trucos como una varia- 
cion aleatoria de color en la piel o 
cambiar los colores de otras partes del 
modelo, lo mejor sera eliminar las tex- 
turas traducidas. De esta manera, las 
piezas asumiran la textura indicada en 
orco.inc, la cual puede ser distinta a la 
usada en el modelo-copia anterior, 
puesto que dicha textura puede ser al- 
terada en el fichero de escena. 

Simulation de jerarquias en 
«P0V» 

Hemos dicho en las h'neas anteriores 
que hay que preparar un archivo que 
establezca un sistema de jerarquias en 
«POV» que imite al que tendrfa el mis- 
mo modelo en «Imagine». De esta ma- 
nera, podremos hacer girar por ejem- 
plo una mano o un brazo complete 
segun lo que nos propongamos. Quiza 
el lector se extrafie ante esto y se pre- 
gunte si verdaderamente es posible y la 
respuesta es que si que lo es, si segui- 
mos unas reglas bien sencillas. 

El modelo complete) es una union o. 
mejor dicho, una union de uniones, 
donde cada union establece una agru- 
pacion jerarquica de los objetos del 
modelo. Hay una para el brazo dere- 
cho, otra para el izquierdo. etc. Ahora 
veamos un ejemplo extraido del archi- 



vo orco.inc, donde hemos definido las 
relaciones jerarquicas de nuestro orco: 



posturas algo forzadas comprobaremos 

que las formas del brazo estan huecas. 

Lo mismo es va- 



Ejemplo de relacion jerarquica para el brazo derecho del orco 



//brazo derecho 
unidnf 

uni6n(object{antebd} 
objectfmunned} 
//la mano y su arma cogen tambien el giro del antebrazo 
union{object{manod} objectjarma} 
translate<39.5 — 75,— 2.5> 

rotate <rmanodX, rmanodY, rmanodZ> 
translate<— 39. 5. 75, 2. 5> 

} 
translate<38 — 104,— 12> 
rotate <rantebdX, rantebdY, rantebdZ> 
translate<— 38,104,12> 

} 
object{brazod) 
translate<25— 136,— 9> 
rotate <rbrazodX, rbrazodY, rbrazodZ> 
translate<— 25,136,9> 



En este ejemplo se define la jerar- 
quia para el brazo derecho de nuestro 
orco. Este brazo esta compuesto por las 
siguientes piezas: la que define la for- 
ma del hombro y biceps, la del antebra- 
zo y la del pufio. Ademas hay una mu- 
nequera, y tambien ha de tenerse en 
cuenta al objeto que el orco siempre tie- 
ne agarrado en el pufio derecho (y que 
puede ser la espada, la maza o el estan- 
darte). No hay, pues, piezas aparte para 
el codo o el hombro, lo que significa 
que si hacemos adoptar al brazo ciertas 



lido para el resto 
de los miembros 
del modelo. 

Ahora veamos 
como funciona 
todo esto. Como 
recordaran los 
«POV»adeptos. 
los objetos en 
«POV» giran en 
torno al eje en 
que se establece 
la rotacion y los 
tres ejes, X, Y y 
Z, se cruzan en el 
centra del univer- 
so virtual de 
«POV», en el 
punto <0, 0, 0>. 
Asi pues, si por ejemplo creamos una 
esfera centrada en la posicion <0, 0, -5> 
y le efectuamos una rotacion de 90 gra- 
dos en el eje X, entonces la esfera gira- 
ra en torno a este eje quedando centrada 
en la posicion <0, 5, 0>. En cambio. si 
la esfera estuviese centrada, por ejem- 
plo en el punto <-10, 0, 0>. entonces se- 
guiria centrada en el mismo punto des- 
pues de la rotacion y giraria 90 grados 
sobre si misma ya que el eje X del uni- 
verso pasa por su centra. Asi pues, si 
pretendiesemos hacer girar uno de los 
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brazos del orco, no bastaria con indicar 
la operation de rotation, sino que antes 
deberiamos trasladar el brazo entero de 
manera que su eje local coincidiese con 
el centra de coordenadas <0, 0. 0>. Si 
no obrasemos asi, el brazo se saldria 
del hombro al efectuarse la rotation. 

Por tanto, y siguiendo con el mismo 
ejemplo, para girar el brazo (o cualquier 
otro objeto) tendremos que seguir tres 
pasos: trasladar el brazo de modo que 
su eje local coincida con el eje del uni- 
verso en torno al cual queremos girar, 
efectuar la rotation y por ultimo aplicar 
al brazo una traslacion inversa a la pri- 
mera, de manera que el brazo vuelva a 
quedar encajado en el hombro. 

Todo esto no sen'a preciso si «POV» 
dispusiera de una instruction para efec- 
tuar rotaciones en torno a un eje local, 
pero dicha instruction no existe (o al 
menos es desconocida por nosotros). 
Ahora bien; ^que valores daremos a las 
operaciones de traslacion que enmarcan 
a cada operation de rotation? 

Evidentemente, los valores que co- 
rrespondan a los puntos donde hemos 
determinado que se hallen los ejes lo- 
cales (recordad que previamente debe- 
remos haber establecido desde el mo- 
delador los ejes locales de todas las 
piezas que puedan girar; en nuestro or- 
co se torno nota de dichos ejes desde 
«Rhino»). Por ejemplo, hemos decidido 
que el eje local del brazo derecho com- 
plete de nuestro orco este en la position 
<25, -136, -9> (este punto esta locali- 
zado, a ojo, en el centra del hombro de 
nuestro modelo). Por tanto, para girar 
el brazo derecho de nuestro orco, he- 
mos escrito las siguientes sentencias: 

translate<25 — 136,— 9> 

rotate <rbrazodX, rbrazodY, rbrazodZ> 

translate-;— 25,136,9> 
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Probablemente tanta prolijidad os 
resultara molesta pero hay que asegu- 
rarse de que estos puntos quedan tia- 
ras. Las variables rbrazodX, rbrazodY 
y rbrazodZ son las que especifican la 
cantidad de grados que el brazo va a 
girar en el eje local declarado. Hay va- 
riables con nombres parecidos para ca- 
da articulation y los valores de rota- 
tion para ellas se establecen en otro 
fichero donde, gracias a dichos valo- 
res, se indica la postura que deseamos 
para el orco. Y con esto ya hemos ex- 
plicado como giran los miembros del 
cuerpo del orco. 

Ahora pasaremos al siguiente tema: 
^Como podemos simular jerarqufas en 
«POV»? 

Echad un nue- 
vo vistazo al lis- 
tado de ejemplo 
anterior. En la 
union mas inter- 
na estan los ob- 
jetos manod y 
arma, los cuales 
giraran en torno 
al eje local defi- 
nido para la ma- 
no (si la mano 
derecha del orco 
no empunase un 

arma no seria preciso declarar una 
union aquf, y bastaria con incluir las 
transformaciones dentro del objeto 
manod). Luego, siguiendo hacia afue- 
ra, veremos que la union manod-ar- 
ma forma parte de otra union com- 
puesta tambien por los objetos antebd 
(antebrazo derecho) y munned (mu- 



nequera derecha). Al final de la union 
encontraremos las sentencias de tras- 
lacion y rotation que afectaran a todo 
el antebrazo permitiendole girar en 
torno al eje local situado a la altura 
del codo. Esta union forma parte de 
otra, mas exterior, de la que el objeto 
brazod es el otro componente -he- 
mos llamado brazod a esta pieza para 
indicar que su giro afecta al brazo 
completo. aunque el objeto en si solo 
se refiere a la parte superior del bra- 
zo. Esta zona incluye al hombro y 
acaba a la altura del codo-. Como ya 
imaginareis, las sentencias de trans- 
formation para esta union afectan a 
todo el brazo. 



Otra prueba de horda 
cambiando la semilla de rand. 






Cuando «POV» vaya a procesar el 
trozo de codigo del brazo completo, 
comenzara a trabajar con los objetos 
o uniones mas internos, efectuando 
primero las rotaciones para la mano 
y el arma asida por esta (en caso de 
que hayamos dado valores a las va- 
riables de esta zona). Luego, se pro- 
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cesaran las rotaciones para el antebra- 
zo completo y finalmente se ejecuta- 
ran las del brazo entero. Por tanto, 
cuando vayamos a crear un archivo- 
plantilla para otro modelo antropo- 
morfico, deberemos tener presente 
que lo mas sencillo es escribir el con- 



junto desde dentro hacia afuera, co- 
rrespondiendo las piezas de la union 
mas interna a las mas extremas del 
miembro tratado. 

Para la pierna derecha. por ejemplo, 
el orden sen'a pie, pantorrilla-pie, pier- 
na-pantorrilla-pie, siendo el pie el ob- 



jeto mas interno de la estruc- 
tura (echad un vistazo a or- 
co.inc). Todo esto es aplica- 
ble a todas las piezas del 
modelo completo y la unica 
dificultad real estara en de- 
cidir sobre la jerarquia de 
ciertas piezas (y por tanto 
sobre su colocacion dentro 
del archivo). 

Es facil ver que la mano de- 
ne un nivel jerarquico mas in- 
terno que el antebrazo pero... 
^.donde situaremos la pelvis o 
la cabeza? En el caso de 
nuestro orco hemos ordenad 
esto de manera que hay varias 
uniones con el mismo nivel 
jerarquico. Los brazos (ente- 
ros) y la cabeza. por ejemplo. 
tienen el mismo nivel jerar- 
quico y ambos forman parte 
de la union que incluye al to- 
rax y que tiene su eje local a 
la altura del cinturon del mo- 
delo. Luego hay otra union 
del mismo nivel que la ante- 
rior y que incluye a las pier- 
nas (enteras), la falda. la pel- 
vis y el cinturon. Ambas 
uniones principals estan en- 
globadas dentro de la union 
principal (el cuerpo entero) 
cuyas operaciones afectan a 
todo el conjunto. 

De esta manera, un valor 
dado, por ejemplo, a ran- 
tebdZ hard doblarse el brazo mientras 
que otro dado a rtoraxZ hara doblarse a 
todo el orco de cintura para arriba. Y 
con esto, ya deberiais estar en condi- 
ciones de crear vuestras propias plan- 
tillas jerarquicas para tratar a otros mo- 
delos, ya sean antropomorficos o no. 
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Creation de ficheros-postura 

Llamaremos ficheros-postura a los 
archivos donde se dan valores a las va- 
riables de rotacion que definen las pos- 
turas de los modelos-copia. Algunos de 
estos ficheros son orcandal , orcombat, 
orcascal, etc. Los numeros impares 
(cuando los hay) corresponden a pos- 
turas nuevas y los pares a posturas don- 
de se han intercambiado los valores de 
rotacion de los brazos y piernas. Estu- 
diadlos y empleadlos como plantilla 
para crear los vuestros propios. 

Una vez que se tiene practica, pue- 
den crearse posturas directamente 
usando un editor de textos. Si ya es- 
tais pensando en preparar vuestros 
propios modelos usando es- 
te sistema. tened presente 
que convendra comprobar 
desde «POV» si cada nueva 
postura es correcta. Para ello 
lo mejor sera generar una es- 
cena con al menos tres co- 
pias de la nueva postura y 
darles distintas orientaciones 
con respecto a la camara. Es- 
to es especialmente reco- 
mendable si hemos estado 
utilizando en «Imagine» otro 
modelo antropomorfico -en 
vez del original- como en el 
presente caso. 

Finalmente comentaremos 
una ultima cosa. Si el lector 
examina la escena del ejercito 
orco avanzando y su fichero de genera- 
tion correspondiente (marcha,«POV»). 
se dara cuenta de un curioso detalle: 
la escena solo utiliza dos posturas, or- 
candal y orcanda2. pero todos los or- 
cos parecen algo diferentes entre si; 
unos tienen las piernas mas levantadas 
o las rodillas mas dobladas que otros, 



los hay que adelantan mas el brazo, 
etc. Esto se debe sencillamente a que 
hemos incorporado en los dos fiche- 
ros-postura una pequena variacion 
aleatoria para algunas de las jerarqufas 
del orco. En efecto, cada vez que el fi- 
chero de escena incluye a uno de los 
archivos orcanda, estos llaman repeti- 
das veces a un ficherito-funcion crea- 
do por nosotros donde se da un valor 
aleatorio a la variable "variacion", la 
cual es luego sumada a las variables 
de rotacion. Antes de llamar a este fi- 
cherito de nombre funcal.pvm, hay 
que dar un valor a la variable-parame- 
tro "signo". Normalmente, pondremos 
el valor 255 en esta variable, indican- 



dremos a "signo" con el valor +1 o -1 
segun el sentido del giro que deseemos 
impedir. Pero esto no es todo. 

Desde el fichero escenico daremos 
tambien un valor a la variable "vari- 
rand", la cual es usada en funcal.pvm 
para establecer el rango de variaciones 
que deseamos para "aleatorizar" los 
grados originales de la postura (en 
marcha.pov hemos usado el valor 30. 
Logicamente cuanto mayor sea este 
valor, mayor sera el rango de variacio- 
nes aleatorias para las posturas origi- 
nales). Podemos aplicar este truco a to- 
das nuestras posturas para conseguir 
asi rehuir un poco la impresion de que 
la escena esta compuesta solo por unas 




Un experiment*) con un cuadro de lanceros-mesh 






do asi que "variacion" puede ser posi- 
tiva o negativa. pero en ciertos casos, 
como por ejemplo en el de una pier- 
na, no nos interesara que la variacion 
tenga un sentido determinado, ya que 
entonces podrfa suceder que el miem- 
bro adoptase una postura anatomica- 
mente indeseada. En estos casos pon- 



pocas posturas pero, atencion, no po- 
demos usar esta idea siempre. En las 
piernas, sobre todo, corremos el ries- 
go de que estas se hundan en el suelo 
si permitimos cualquier variacion. 
Otra posibilidad de fallo es que uno de 
los brazos del orco se hunda en su pro- 
pio cuerpo asi que , . . j cuidado ! 
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Una escena cualquiera con 
cientos de actores 

Para visualizar mejor como funciona 
todo esto vamos a repasar como se ge- 
nera una cualquiera de estas escenas. 
Por ejemplo, en marcha.pov, se especi- 
fica primero la pigmentacion "ideal" 
de los orcos. Luego se incluyen todas 
las piezas que pueden aparecer en la 
escena (del cuerpo, las cabezas, las ar- 
mas...). Despues, asignamos valores a 
una serie de variables que se emplea- 
ran en ficheros posteriores y luego se 
entra en un bucle anidado con el que 
crearemos un ejercito construyendo 
bloques de regimientos. Cada regi- 
miento sera creado al invocar al fiche- 
ro regiorc.inc, archivo que utilizara las 
variables anteriores para decidir el an- 
cho del regimiento, su numero de filas, 
si llevara un portaestandarte al frente, 
etc. La separacion entre regimientos y 
otros detalles tambien se especificaran 
antes del bucle. 

Una vez en regiorc.inc, 
«POV» hallara otro do- 
ble bucle con el que 
construira el regimien- 
to. En cada caso se 
decidira si el orco 
llevara es- 
cudo, su 
tipo de 
arma, su 
inclina- 
cion late- 
ral de ca- 
beza, etc. 
Pero lo mas im- 
portante es que 
-segiin el valor 
de la variable ti- 
poej- se deci- 
diran cuales 




seran los ficheros-postura a emplear. 
Si tipoej vale 1 , se creara al ejercito 
usando las posturas de los archivos or- 
canda, con lo cual obtendremos un 
ejercito marchando. En cambio, si ti- 
poej tiene otro valor, entonces se usara 
el archivo orcombat.inc, el cual creara 
poses de combate. En este ultimo caso 
obtendremos un ejercito a punto de en- 
trar en batalla, con nuestros persona- 
jes exhibiendose en diferentes postu- 
ras de provocacion hacia el enemigo. 
Puede parecer mentira el que todos los 
horcos de esta horda hayan sido crea- 
dos tan solo con este unico archivo, pe- 
ro en realidad el truco es muy simple. 

Ante todo se crearon dentro de este 
archivo una serie de poses individua- 
ls para los miembros del orco. Hay 
tres posibles colocaciones para el bra- 
zo derecho, dos para el brazo izquier- 
do y una (por ahora) para las piernas. 
Ademas de esto cada una de estas po- 
sibles colocaciones puede sufrir varia- 
ciones aleatorias dentro de ciertos ran- 
gos calculados para impedir que el 
personaje se atraviese con su propia 
arma (pues, si, esto sucedio en las 
pruebas iniciales). En resumen: en ca- 
da pasada de orcombat.inc se estable- 
ce aleatoriamente el brazo que va a 
colocarse y las variaciones aleatorias 
correspondientes. El resultado se 
guarda en las variables de rotacion 
que mas tarde se pasaran a orco.inc 
desde regiorc.inc. 

Todo esto puede parecer muy com- 
plicado al principio pero desenganaos; 
no lo es. Lo realmente importante es 
que entendais como pueden crearse je- 
rarqufas simuladas en «POV». Lo de- 
mas (la creation de posturas, regimien- 
tos o ejercitos enteros) podeis hacerlo 
si lo preferis de cualquier otra manera. 




Futuras 
escenas 
con mesh 

Visto es- 
to es facil 
imagi nar 
muchas posibles escenas interesantes 
que son posibles con mesh. Con esta 
sentencia ya no serfa imposible crear 
ciudades gigantescas o grandes flotas 
espaciales o incluso algo como un 
hormiguero. 

Como mesh puede ser usada en 
conjuncion con las llamadas senten- 
cias de progratnacion, las posibilida- 
des son casi ilimitadas. Tan solo ve- 
mos un problema: aun no hay manera 
de determinar -utilizando colocacio- 
nes aleatorias- si dos modelos se estan 
superponiendo. Esto puede ser bastan- 
te molesto (en las primeras pruebas 
muchos de los orcos se ensartaban 
unos a otros). Contra esto, por ahora, 
la unica solution es controlar el espa- 
cio de separacion de cada elemento, 
usar bucles de colocacion que eviten 
que se trate dos veces una misma zona 
espacial y esperar que haya suerte. 



ACERCA DE SPATCH 

El mes pasado incluimos en el CD- 
ROM un programa llamado «sPatch» 
que se distribuia gratuitamente a 
traves de la red Internet y que, segun 
lo que podia leerse en el sitio Web del 
autor, nunca caducaba. A pesar de 
esta afirmacion, «sPatch» ha caducado 
inesperadamente con el ano 97, as! 
que incluimos ahora la nueva version. 
Dada la imprecision de la version 
anterior, no podemos asegurar que 
esta funcione cuando se publique la 
revista. Para mas informacion os 
remitimos al Web del autor: 

http://www.aimnet.com/~clifton/spatch.html 
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Nota importante. Podeis remitirnos vuestros trabajos o consultas, bien por carta a la direction que 
figura en la segunda pdgina de Panama, o via e-mail a rendermania.pcmania@hobbypress.es 



Mundos Fascinantes 



Como bien dice Jesus Angel 
Lanza Salcines, aunque 
sepamos muy bien que el 
corazon de nuestro 
ordenador es un frio chip de 
silicio, al otro lado de la 
pantalla de nuestros 
monitores pueden existir 
mundos fascinantes que tan 
solo esperan a que nosotros 
sepamos hacerlos realidad. En 
ese otro lado puede haber poesia, 
belleza, fantasia e incluso horror. 
Lo que hallemos dependera, como 
siempre, de nuestro esfuerzo y de 
la riqueza de nuestro propio 
mundo interior. Y es que algunos 
autores (volviendo a citar a Jesus) 
prefieren considerar a la pantalla 
del ordenador no como frio 
hardware, sino como la puerta a 
un mundo magico. 




Probablememe cuando echeis un vistazo a las maravillosas es- 
cenas de Jesus Angel Lanza Salcines os quedareis tan asom- 
brados como yo mismo. Y es que las escenas de este maestro del 
«Caligari Truespace» no son simples imagenes renderizadas. 
Mas bien parecen puertas a universos donde se estan desarro- 
llando historias como las que cuentan Tolkien, Zelazny. Moor- 
cock y otros maestros de la fantasfa. Son escenas soberbias, 
fantasticas, alucinantes, donde las chicas de Jesus no parecen 
mallas poligonales sino personajes vivos y adorables. 
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Seguimos hablando de la obra de Jesus Angel Lanza Sal- 
clnes. En cuanto a los datos tecnicos, poco es lo que pode- 
mos decir sobre la chica. Los datos incluidos por Jesus di- 
cen que Pamela tiene unas 6200 caras (cuesta creerlo, 
^verdad?). Y tampoco podemos explicar nada sobre el 
propio autor, ya que no nos ha enviado carta alguna. Tan 
solo contamos con unos interesantes archivos html, donde 
podremos ver escenas y animaciones y leer algunos diver- 
tidos textos relacionados con las imagenes. Podeis encon- 
trar todo esto -junto con otras imagenes que venian en otra 
carta y que no son referenciadas en los archivos html- en 
el directorio lanza del CD. Amigo Jesus, tu chica es extra- 
ordinaria y podrfa en mi opinion competir incluso contra 
Kyoko o Rina (otras dos fantasticas chicas 3D que ya vi- 
mos en el numero 8 de Rendermam'a). Estoy seguro de que 
todos los rendermaniacos desearan tanto volver a verte en 
estas paginas como yo. Hasta entonces dile a Pamela que 
me considere su mas ferviente admirador. 





i Come 
I Escu 



Como podeis ver en esta pagina, el orco de Carlos Monterde 
Escudero ha progresado mucho. Las manos estan muy mejo- 
radas con respecto a las del modelo del numero 1 1 y Carlos ha 
preparado bastantes posturas de este orco creado con el lengua- 
je de «POV». Ademas. Carlos incluye un brujo (tambien com- 
pletamente modelado desde «POV») y ha preparado nuevas ar- 
mas para su orco. Bien por ti pov-colega, pero te recomiendo 
que utilices el metodo que expongo en el presente numero. jTar- 
daras menos en crear posturas y grupos de personajes ! Por otro 
lado el hermano de Carlos. CESAR, nos ha enviado una peque- 
na animacion de la que espera una cn'tica que por una vez no 
voy a hacer (la dejare para tu siguiente animacion). En cuanto al 
reto de vuestro clan de orcos, puede ser que decida aceptarlo y 
quiza, quiza, os lleveis una sorpresa. 
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Otro par de hermanos: Al- 
berto v Oscar Otero Leal 
nos envfan un par de mechs 
creados con «MAX». Am- 
hos hermanos incluyen una 
carta explicando los deta- 
lles de la construccion de 
sus modelos y las caracte- 
n'sticas tecnicas de cada 
mech y me piden que diga 
cual de los dos me ha gus- 
tado mas (y ademas acla- 
ran que no aceptaran un empate). Ambos hermanos aducen las diferentes ventajas de sus mechs y Os- 
car, por ejemplo, afirma que cree al suyo capaz de cualquier mision. j Pues bien, no lo creo! Dudo que, 
por ejemplo, fuese capaz de tomar el te en el salon de mi casa y por dicha razon le descalifico y doy 
la victoria al de Alberto. Bueno, ahora en serio, os habeis olvidado de especificar que imagen co- 
rresponde a cada mech aunque creo que me gusta mas el bianco ya que su forma me parece mas ori- 
ginal que la del negro. Por supuesto que aceptare a vuestros modelos para la escena de mechs. que co- 
mo veis se esta retrasando un poco (problemas de conversiones). 



Luis Perez. Monpean ataca de nuevo con dos 
imageries creadas con «POV». Esta vez se trata 
de una habitacion y de una replica aproximada 
del escenario empleado por U2 para su gira 
"Pop Mart". Pues bien, ya que pides una critica 
te dire que la pega principal es que tus imageries 
podn'an haber ganado bastante si hubieras usa- 
do esas sentencias de programacion de «POV» 
que aiin no has tenido tiempo de aprender. No 
temas: no voy a enviarte un Mech trazado con 
rayos a que te tire de las orejas para que las es- 



tudies, pero si quiero hacerte notar que si las hubieras usado probablemente tus escenas habrfan ga- 
nado mucho con muy poco esfuerzo adicional. Por ejemplo. habrfas podido emplear #while para las 
vallas del estadio o para dar algo de detalle a las gradas del mismo e incluso para el mismo armario. 
Tomo nota de tu sugerencia para la ciudad-portada pero antes habrfa que especificar algunas reglas de 
construccion <■ no? A fin de cuentas un chalet o un templo romano no pegan en medio de una ciudad 
de rascacielos moderna. Hasta la proxima. 




Francisco J. Serrano Rev nos envi'a una 
imagen de su tanque escorpion que desea 
vender y solicita una opinion. Bueno pues. 
sin animo de desanimarte y sin decir en mo- 
do alguno que tu modelo sea malo, he de se- 
nalarte que incluso los mejores infografistas 
lo tendrian dificil para vender un linico mo- 
delo. Ademas, tu tanque estii restringido a 
un campo muy limitado (un buen modelo 
humano lo tendrfa algo mas facil). Mi con- 
sejo es que, si tienes algo visualizable de ese videojuego estrategico del que hablas. te acerques a al- 
guna casa de soft. Otra posibilidad es trabajar como infografista en alguna casa de juegos. Pero 
mientras buscas, mi consejo es que sigas practicando, ya que solo cuando se alcanza un nivel de ha- 
bilidad verdaderamente espectacular hay esperanzas de lograr un trabajo en este mundillo. jSuerte! 





Benjamin Albares Moreno 

recibe mi mas sentido pesame 
por la disolucion de tu grupo y 
tambien mi mas sincera felici- 
tation por tu estupendo Mech. 
Me alegra tu intencion de par- 
ticipar en la convocatoria de la 
portada sobre Mechs (que co- 
mo ves. se va a retrasar un po- 
co) pero lo que dices es bien 
cierto; tu mech emplea mu- 
chas texturas que yo habrfa de 
aplicar pieza a pieza desde 
«POV» ya que no conozco 
ningun conversor que "traduz- 
ca" tambien la aplicacidn de 
las texturas. <,Que hacer? Aun 
no lo se. En cuanto a tu suge- 
rencia para el collage, desde 
luego es lo que menos trabajo 
me costan'a pero la verdad es 
que prefiero preparer una por- 
tada normal, aunque no voy a 
descartar tu idea. 

Por ultimo quiero felicita- 
ros a ti y a David Lozano Lu- 
cas por vuestra revista electro- 
nica "Euro 3d Design" deed 
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los detalles en la carta de Ben- 
yi). Para ella. como dice 
Spock; jLarga y prospera vida! 
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uolcado dc nnidinciones • produccioo v postproducciod digitrl dc uideo 

cTe gustan tus trabajos 2D/3D? 



Entonces, <j,por que los 
terminas en formato AVI, FLI, 
o con tarjetas MPEG de baja 
calidad, cuando puedes 
obtener resultados 
verdaderamente 
profesionales a un coste 
razonable? 

Si eres usuario de AutoCAD, 3D Studio, Animator Pro, Lightwave, 
POVRay, etc. y quieres tener tus propias animaciones volcadas a 
video en calidad Broadcast Betacam, asi como toda una serie de 
servicios adicionales, llamanos y te informaremos. 



^Te imaginas? 

Poder ver en video cualquiera 
de tus animaciones. 




I 



Increible! 
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No lo pienses 
LLamanos 

571 3142 

Recogida y envfo de trabajos a toda Espaha concertada con 



Fax : 571 3501 

E-mail : a-sp@infornet.es 

Web: http://www.a-sp.com 
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